1. Field of the Invention
Then present invention relates to virtual local area networks, VLAN's, and more particularly to private VLAN's or PVLAN's.
2. Background Information
Virtual local area networks (VLAN's) represents a broadcast domain, where a client can send frames to any other client in the same VLAN. However, this arrangement presents security issues where other clients can monitor the traffic in the VLAN. Private VLAN's (PVLAN's) were invented to address this security issue.
Several prior U.S. patents, discussed below, describe the environment of the present invention.
U.S. Pat. No. 5,394,402, issued on Feb. 28, 1995 to Ross ('402). This patent is hereby incorporated herein by reference. This patent discloses that physical ports of a particular switch may be associated with groups within the switch by creating a table associating the ports with a VLAN designation. The VLAN designation and associated switch ports may be used in headers to direct messages sent to or received from any ports assigned to the VLAN designation. A memory is provided to store these associations that are usually in the form of tables.
Typically, the switch is a computer with one or more CPU's, memory and input/output (I/O) cards. Each card may include a limited number of ports that couple the switch to the other network entities over various types of media, such as Ethernet, FDDI (Fiber Distributed Data Interface) or token ring connections. A last hop or edge switch (or router) sends and receives messages, typically frames, to and from end users (Clients) over a communication network, e.g. the Internet. The edge switch typically contains an operating system, a route information base (RIB), a forwarding information base (FIB) and a management information base (MIB), hereinafter collectively referred to as an “information base,” that allows the switch to receive and forward messages regardless of the end user protocol.
U.S. Pat. No. 5,959,989 ('989) issued Sep. 28, 1999 and is commonly owned with the present invention and is hereby incorporated herein by reference. This patent describes an invention for multicast distribution in VLAN's. Port addresses are associated with VLAN designations and with MAC (Media Access Control) addresses that are then arranged in groups for distribution. MAC addresses are typically hardwired in network interface cards (NIC).
The above references further describe VLAN's where a port is configured in one VLAN only, and where a port in one VLAN does not send traffic to a port in another VLAN. The following discussion introduces PVLAN's, where a port receives and/or sends information via at least two different but related VLAN's.
U.S. Pat. No. 6,741,592 ('592), issued May 25, 2004 and is commonly owned with the present application. The '592 patent is hereby incorporated herein by reference. This patent describes PVLAN's as three related VLAN's defined within a layer 2 (L2) switch. The three VLAN's are defined as one primary, one isolated and/or multiple community VLAN's. The isolated and community VLAN's collectively are referred to herein as secondary VLAN's. PVLAN's introduce three related ports, defined, respectively, as promiscuous, isolated and community. The promiscuous ports are connected to layer 3 (L3) or layer 4 (L4) devices, for example, routers that may in turn connect to the Internet or administrative work station or common net work servers, e.g. a Dynamic Host Configuration Protocol (DHCP) server. The isolated and community ports connect to individual users' computers or servers, etc. and carry traffic for those users.
A primary VLAN functionally connects the promiscuous ports with isolated or community ports. The primary VLAN receives packets from L3/L4 devices at the promiscuous ports and transfers the packets to the isolated or community ports. The packets travel only one way from the promiscuous ports to the ports in the secondary VLAN's.
An isolated VLAN is defined as a VLAN that functionally connects isolated ports to promiscuous ports. In an isolated VLAN the traffic is only one way—packets are received at an isolated port and travel only from that isolated port to a promiscuous port. Packets are not available to other isolated or community ports.
A community VLAN is defined as a VLAN that functionally connects community ports to promiscuous ports. In a community VLAN the traffic is only one way—packets are received at a community port and travel only from that community port to the promiscuous ports and to the other community ports on that community VLAN. Packets do not travel from a community port to isolated ports, or to community ports on a different community VLAN that may exist on the same switch.
Assignment tables and/or Color Blocking Logic (CBL) logic circuits, found within L2 switches that support PVLAN's, are used in known embodiments of the logic operations, described above, in a PVLAN among the promiscuous, isolated and community ports and the primary, isolated and community VLAN's. Such tables and logic are referenced in the '592 patent and are known to those skilled in the art. But, such logic implementations are specific to particular hardware platforms.
A network security issue is discussed in an article entitled, “Capturing Network Traffic for the Catalyst 6000 IDS Module,” issued by Cisco Press on Feb. 15, 2002. This article is hereby incorporated herein by reference.
The article describes VLAN access control lists (VACL's) for directing communication traffic flow to specific physical switch ports. The VACL's capture traffic in both directions—inbound and outbound from a port on the switch. The Catalyst 6000 IDS Module is a physical printed circuit interface card, and, as such, initialization of VACL's on the physical card requires creating/storing of the VACL's within a data structure (table) mapping the VACL's to specific VLAN's, and defining a VACL capturing port. The Catalyst 6000 IDS Module may have ports configured as Switched Port Analyzer (SPAN) ports that can direct traffic from ports to specific VLAN's or destination ports. However, in either case the physical configuration to implement these operations is intimately tied to the physical hardware and not easily transferred to other platforms.
When configuring a VLAN within an L2 switch using known techniques, an administrator will manually designate ports within the VLAN. However, when configuring PVLAN's, the administrator defines a primary and one or more secondary VLAN's but the MAC addresses associated with the corresponding ports are learned only in the primary VLAN. Learning MAC addresses associated with ports typically occurs dynamically as messages are received at the ports, using, for example, an address resolution protocol (ARP).
In an L2 switch configured to support PVLAN's, a forwarding engine operating with respect to a primary VLAN stores the MAC addresses and port numbers for the users connected to the ports. The MAC addresses of users that are also assigned to secondary VLAN's are not learned in that secondary VLAN. This alters the normal MAC address learning mechanism of typical VLAN's, requiring the PVLAN implementation to be closely tied to the hardware implementation. The above discussed CBL is implemented to effect the transfer of messages between proper ports via the restricted (isolated/community/primary traffic restrictions) and one-way traffic nature of a PVLAN.
Specifically, when a packet is received at an isolated or community port, the receiving port number is used to index into a table where the secondary VLAN designation is found. The packet is transferred to the forwarding engine for that secondary VLAN, and the destination port number from the packet is used to index another table defined for outgoing traffic from the primary VLAN. The L3/L4 destination address and promiscuous port number are retrieved from the table, and the packet is transferred to the forwarding engine associated with the primary VLAN that directs the packet to the proper L3/L4 device. As noted above, these known implementations are closely tied to the physical hardware in the L2 switch and not easily transferred to other platforms.
Typically, a user on a secondary VLAN is unaware of (cannot “see,” is a term of art meaning that there is no reference available to that secondary VLAN) other users on another VLAN. So, a port on one secondary VLAN cannot send traffic directly to a port of the primary VLAN.
The present invention is directed to relieving to the above limitations and untying the PVLAN's from specific hardware platforms.